1. Field of the Invention
The invention relates to a proxy-bridge for connecting Universal Plug and Play (UPnP) compliant devices with Bluetooth (BT) compliant devices. The invention also relates to a method and to a computer program product for enabling such connections.
2. Description of the Prior Art
As described in “Personal Networks Enabling Remote Assistance for Medical Emergency Teams”, by F. T. H. den Hartog, J. R. Schmidt, and A. de Vries, in Studies in Health Technology and Informatics, Volume 114, 2005, pages 221-229, a Personal Area Network (PAN) can be defined as a network of devices in the personal operating space of the user. The user is, for instance, carrying a laptop, a personal digital assistant (PDA), a mobile phone, a wireless headset and a digital camera. The devices are, for instance, networked with each other by means of high-data-rate wireless personal area network (WPAN) technology (>200 kbps). The mobile phone, the laptop and the PDA can also communicate to the rest of the world by means of Universal Mobile Telecommunications System (UMTS) technology or Wireless Local Area Network (WLAN) technology. This configuration enables, e.g., pictures taken by the digital camera to be emailed by means of the email client on the PDA and the UMTS connection of the mobile phone.
A Personal Network PN (not to be confused with a PAN), is envisaged as the next step in achieving unlimited communication between people's electronic devices. A PN provides the technology needed to interconnect the various private networks of a single user seamlessly, at any time and at any place. Such private networks are PANs, home networks, car networks, company networks, and others. Often, a user wants to remotely access content, applications, or resources that are located in one of his private domains. For example, a business man who is at a conference wants to take pictures of the various speakers without having to worry where the pictures should be stored: on the memory card of the camera, the hard disc of the laptop, the content server in the office, or the desktop computer at home. A PN should solve the current limitations that inhibit (user-friendly) access to the personal devices that are not physically close to the user at the moment of need.
Various private and public infrastructures are involved in creating a PN. The PN itself is covering the multiple domains that should hide the underlying network and business complexity from the user. At the heart of the PN is the core-PAN, which is physically associated with the owner of the PN. The core-PAN consists of networked personal devices carried by the user. Depending on the location of the user, the core-PAN can interact with devices in its direct environment or with remote devices in the user's other private networks to create a PN. A key element of the core-PAN is therefore the PN Gateway (PNG). The PNG is the device that contains the functionality needed to create a PN from the core-PAN and the other private networks. This functionality might include, amongst others, local storage, local intelligence, multiple wireless (mobile) access network interfaces, and protocol bridging/proxying functionality. The PNG can be a single dedicated device, or added functionality of other devices in the core-PAN. In the example of the PAN as described before, the PNG functionality is distributed over the laptop, PDA, and mobile phone. Another important factor for enabling a fully functional PN will be the Personal Network Provider (PNP). The PNP is not a device or a specific application, but a new business role. It is basically the service provider offering the PN service and providing an operational environment to manage user, service, content and network related issues. For that purpose the PNP might use a service platform, which communicates with the PNG and offers service control functions that enable end users to easily gain and maintain access to services, while roaming between different interconnecting public infrastructures. For other service providers, the PNP can act as a one-stop shop for providing their services to the PN. The PNP could also take care of the billing, depending on the subscriptions with the various network and service providers, and on the authentication of the devices and content belonging to the PN.
It is becoming clear that PNs in practice not only consist of internet protocol (IP) domains (e.g., using the TCP/IP computer network protocols), but also of non-IP domains. Examples of non-IP domains are car networks and PANs that make use of Bluetooth. This situation raises interoperability problems as for seamless operation of a PN it is a requisite that devices and services present in the PN automatically learn about each other's presence and about ways to make use of each other's services. As far as IP domains are concerned, to a certain extend UPnP can be used for this purpose. For non-IP domains, another protocol has to be used. To that end, the Bluetooth specifications describe the Bluetooth service discovery protocol (SDP). For a heterogeneous PN comprising UPnP and Bluetooth devices to function seamlessly, UPnP and SDP must be bridged. One of the possibilities is to transport IP on top of Bluetooth, for which Bluetooth offers an interface, and run the UPnP stack on top of this. However, this requires ‘light-weight’ apparatuses such as headsets to run a full UPnP/TCP/IP stack, which is undesirable in practice due to cost constraints. Another possibility is to run UPnP without IP on top of Bluetooth, which still requires to run heavy protocols such as UPnP on light-weight devices.
An example of the latter is US Patent Publication No. 2001/0033554 A1, which discloses remote control of devices in a piconet (an ad-hoc network of devices using BT protocol) by remote users communicating over the internet by providing a proxy-bridge device. Universal Plug and Play (UPnP) functionality is provided on top of the L2CAP layer of each Bluetooth (BT) device. Since L2CAP does not support networking functions between piconets, it limits the discovery of services to the active BT devices in a given piconet. Service discovery is extended by the UPnP functionality. In this system, the Service Discovery Protocol (SDP) provides service records indicating the availability of UPnP functionality in a BT device. The document discloses an exemplary BT compliant stack with additional details for providing support for various UPnP features in a suitably modified BT protocol stack. Support for HTTP and Extensible Markup Language (XML) is required for UPnP in the Bluetooth device in order to communicate with IP UPnP devices. A diagram of the communications stack implemented in the proxy-bridge device according to US 2001/0033554 A1 is shown in FIG. 1 herein. The proxy-bridge comprises a UPnP compliant application 145, a table of Bluetooth identifiers and the corresponding IP addresses 150, HTTP and XML 140, SDP 135, L2CAP 130, Bluetooth baseband link controller 110, TCP 125, UDP 120, Internet protocol network layer 115, data link layer 105, and physical layer 100. The document further discloses a proxy-bridge device for extending access to a device in a piconet by an external device residing outside the piconet, the proxy-bridge device comprising: a piconet protocol compliant stack for handling communications between proxy-bridge device and the device in the piconet; an external device compatible stack for handling communications between the proxy-bridge device and the external device; and a database associating an identifier of the piconet device with an external device compatible identifier employable by the external device for addressing the piconet device. It further discloses the proxy-bridge device further having a UPnP component associated with the piconet protocol compliant stack and the external device compatible stack. Herein, the UPnP component includes functionality for sending a service discovery request from the piconet device to the external device and sending a response to the service discovery request from the external device with a description of at least one service available in the piconet. The proxy-bridge device is a master device in the piconet and the piconet device is a slave in the piconet. The piconet protocol compliant stack conforms to BT specifications thereby enabling the proxy-bridge device to interoperate with other BT devices.
In “Controlling non IP Bluetooth devices in UPnP home network”, by Sun-Mi Jun and Nam-Hoon Park, in Advanced Communication Technology, 2004, referred to hereinafter as “Jun et al”, a method for controlling non IP Bluetooth devices in a UPnP home network is disclosed. Jun et al present a UPnP-Bluetooth proxy server to assist the non-IP Bluetooth devices to be connected and controlled on UPnP home networks. The bridge proposed in Jun et al is schematically represented in FIG. 2. The UPnP-Bluetooth proxy server 168 comprises a UPnP message processor 172 receiving 164 service discovery multicast messages and control messages from a UPnP control point through HTTP and transmitting 166 UPnP messages. It also comprises a Bluetooth device discoverer 168 for getting service records of the Bluetooth devices within the piconet using SDP requests 160 and SDP results 162, and passing the service records to a UPnP description generator 170. It also comprises a description table 174 containing the service records of the Bluetooth devices such as Service Name, Device UUID, and Service Handle. The IP port numbers of the proxy server should be mapped to each Bluetooth device to be recognized by a node outside of the Bluetooth piconet. The description table also contains the device descriptions and the service descriptions to be utilized by UPnP middleware. It also comprises a description generator for creating the description table using the results of Bluetooth device discoverer and converting the table to XML documents. Although the description generator creates the device and service descriptions as a form of XML, the system cannot write all items required by the UPnP system in the table as SDP cannot provide access, brokering, and controls of services, but only availability of services and the characteristics of those available services. Therefore, the proxy server also comprises a description table editor for filling in the action fields of the description table in order to execute programs to utilize services of the Bluetooth devices. The editor provides users a mean to configure the description table for utilizing services. The user here is meant to be the administrator of the proxy server.
The description generator of Jun et al uses SDP to get the fields available in SDP. Several fields required in the UPnP description of the device are not available in the SDP results. In particular, the service description URL, the control URL, and the event URL cannot be extracted from the SDP results. Also the fields relating to UPnP service description cannot be extracted from the SDP results. The description generator fills in some of these attributes as follows. The Service Description URL is the HTTP location of the UPnP service description stored in the proxy server. The Control URL is the HTTP location receiving the messages from UPnP control points, specified by a UPnP vendor and registered by the proxy server's administrator. The Event Sub URL field is related to the UPnP events, specified by a vendor, and unique for a device. If a service has no event, this field should be empty.
A Bluetooth master and a device composing a connection unit have a pair of application programs for connecting each other. The application program may be a profile defined by Bluetooth SIG or a customizing application. The UPnP-Bluetooth proxy server of Jun et al, which is operated as a Bluetooth master, has some programs for accessing its slave devices. This server also knows the execution locations of the programs and the arguments passed to the execution programs. These execution locations and arguments should be recorded to the action and arguments fields of the UPnP service description. In a Bluetooth piconet, Bluetooth devices send events to their Bluetooth master whenever the states of those are changed. To process the events of the Bluetooth devices on UPnP network, the UPnP-Bluetooth proxy server's administrator defines the state variable mapped to each event of a the Bluetooth device, and registers the variables and their attributes to the state variables fields of the UPnP service description. After the administrator's configuration, if a Bluetooth device sends an event relating to a state change, the mapping state variable of the UPnP service description should be modified and the result is send to the UPnP control point via the Event Sub URL.
The systems disclosed in the prior art are not capable of connecting all existing combinations of UPnP devices and Bluetooth devices. Some require a more complex communication stack in the Bluetooth devices. Moreover, they require manual maintenance and are relatively inefficient in keeping the devices up-to-date regarding available devices.